2. Scenario 2: Cross-Enterprise Application
In this scenario,
two partner enterprises would like to collaborate on each other's
collaboration platforms. Enterprise A is a software company that
manufactures operating system software. Enterprise A has partner
companies (OEMs) that customize these operating systems, install those
systems on their hardware, brand the integrated platform, and sell the
product to consumers through their sales channels. The end product may
be a personal computer, a laptop, or even a cell phone. For this
example, Enterprise B is an OEM of Enterprise A. To launch a particular
product in time, Enterprise B needs early access to some of the
software releases and documentation associated with those releases.
Enterprise A, on the other hand, needs information about sales of the
end product to use for sales and revenue tracking of its own product.
Enterprise A has a
dedicated web application named PartnerAccess in its extranet for OEM
partners. The PartnerAccess web application supports role-based
authorization for different roles in multiple partner enterprises. Some
example partner roles are Partner_Manager, Partner_Employee, and
Partner_Contractor.
Enterprise B has a list
of users configured in Enterprise A's Active Directory who have access
to the early release operating system software through the web
application in Enterprise A's extranet. Enterprise B users log in to
this application using their Enterprise A credentials. Enterprise A's
administrators find it difficult to track and maintain users of
Enterprise B and other partners because the administrators have to
delete or modify partner users when they quit their company or are
promoted to another position. The total number of partner users numbers
hundreds of thousands across multiple OEM partners. Maintaining these
partner user identities has become expensive for Enterprise A, and the
company is looking forward to reducing its identity-management costs
for the PartnerAccess web application.
On the other side of the
equation, Enterprise B has a similar problem maintaining Enterprise A
identities for thousands of Enterprise A employees and contractors in
its SalesAccess software. The SalesAccess software provides sales
information to Enterprise A. Enterprise A users log in to the
SalesAccess software using their Enterprise B credentials, to acquire
real-time sales information from Enterprise B. Other partner companies
also have similar applications providing sales data access capabilities.
As an architect, I
recommend that Enterprise A design a claims-based identity model for
its PartnerAccess web application and use ACS to abstract the partner's
identity provider from PartnerAccess. The partner enterprise (such as
Enterprise B) owns the responsibility of authenticating its users. The
recommended design is illustrated in Figure 2.
The following steps describe the flow of information for the PartnerAccess web application:
Step 0: The PartnerAccess web application completes all the prerequisites required to make ACS work for the application. In Figure 2,
the important steps are establishing trust between PartnerAccess and
ACS using a shared key, which is refreshed on a periodic basis; having
the PartnerAccess administrator and Enterprise B administrator
configure ACS to trust Enterprise B's Geneva-federated identity
provider to generate STS for Enterprise B users; and having
PartnerAccess define the mapping between input claims from Enterprise
B's Geneva Server–generated SAML tokens and output claims in the form
of rules specific to the PartnerAccess application. This is where the
administrator can define different claims for different roles for
Enterprise B employees.
Step 1:
When an Enterprise B employee wants to sign in to the PartnerAccess web
application, the employee is authenticated with Enterprise B's Active
Directory, and the ADFS 2.0 generates a SAML token for ACS. Because
Enterprise B is in control of its employee identities, and Enterprise A
trusts Enterprise B's authentication process, it makes sense to
delegate the authentication of Enterprise B's employees to Enterprise B.
Step 2: The SAML token generated by Enterprise B's ADFS 2.0 is sent to ACS. The SAML token consists of input claims to ACS.
Step 3:
ACS maps the input claims from the SAML token to output claims specific
to the PartnerAccess web application and packages them into an SWT
token.
Step 4:
The SWT token with output claims is sent to the PartnerAccess web
application for processing. The PartnerAccess application processes
these claims in a claims-processing module and determines the level of
access the Enterprise B employee is entitled to. The PartnerAccess web
application doesn't need to authenticate Enterprise B users in the
Enterprise A environment because it trusts SWT tokens generated by ACS.
The introduction
of ACS into Enterprise A's environment and federating Enterprise B
identities using Geneva simplifies the management of the partner
accounts. Enterprise A can reuse this configuration for all the
partners accessing the PartnerAccess web application, whereas
Enterprise B can reuse Geneva Server to federate identities across
multiple partner companies. Note that the PartnerAccess web application
isn't dependent on the identity providers of partner companies. As long
as a trust is established between ACS and the partner identity
provider, the PartnerAccess application does the necessary claims
processing for any partner.
For the SalesAccess web
application, Enterprise B can implement the same pattern by introducing
ACS in the architecture and letting Enterprise A employees authenticate
and generate SAML tokens using Enterprise A's own ADFS 2.0. With the
same pattern implemented in Enterprise B's architecture, Enterprise A
and Enterprise B can access each other's applications seamlessly by
removing the identity-management burden from the partner company. The
identity management remains with the company that owns the identities.
